Thanks for the pull request, @jacobo-dominguez-wgu!

This repository is currently maintained by @openedx/committers-frontend.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

Sorry I haven't been following the frontend closely, just a question about the system scoped roles. Are these just users who have explicitly been given permissions in the given course/library, or would it include everyone with Staff / Superuser? I'm just concerned about it since very large instances could have dozens of those users and easily overwhelm the useful information.

Sorry I haven't been following the frontend closely, just a question about the system scoped roles. Are these just users who have explicitly been given permissions in the given course/library, or would it include everyone with Staff / Superuser? I'm just concerned about it since very large instances could have dozens of those users and easily overwhelm the useful information.

In my understanding system roles like Global Staff and Super Admin are shown with global access to all scopes and all organization like this (one row per user):

So in case of having dozens of these it may overwhelm the useful information as you mention, but the filters can be useful to prevent this situation.
Correct me if I am wrong @gviedma-aulasneo, @rodmgwgu

Sorry I haven't been following the frontend closely, just a question about the system scoped roles. Are these just users who have explicitly been given permissions in the given course/library, or would it include everyone with Staff / Superuser? I'm just concerned about it since very large instances could have dozens of those users and easily overwhelm the useful information.

In my understanding system roles like Global Staff and Super Admin are shown with global access to all scopes and all organization like this (one row per user): So in case of having dozens of these it may overwhelm the useful information as you mention, but the filters can be useful to prevent this situation. Correct me if I am wrong @gviedma-aulasneo, @rodmgwgu

Yes, we are working on the assumption that the filter will be enough to solve this problem. We are developing under the assumption that large and complex instances are less common than their counterparts; we may change the approach if we get stronger feedback for the next iteration.

@gviedma-aulasneo would it be worth considering making the system users filtered by default since (I assume) there is no action that can be taken on them?

@gviedma-aulasneo would it be worth considering making the system users filtered by default since (I assume) there is no action that can be taken on them?

We can discuss it, of course. The main reason they are listed here is transparency around who has access to the courses and libraries. I will add, only as context, that we even discussed whether this should be visible only to course/library admins and that there was also some discussion about placing them in a separate tab.

It seems less likely that we would change the designs for Verawood, and forcing this now would likely result in a poor UI. The current UI responds to filters by showing that they are applied, so using a default filter here would look a bit hacky. In practice, this would mean having a default view with all non-superuser roles selected as filters from the start, which does not seem like the best approach right now.

The designs for Willow are still being refined. A new way of grouping the list entries by user will help declutter the current view and make it easier to read. Unless you consider this to be something we should give more thought to, we can discuss showing superadmins in a separate list there.